猜猜看，工程師與設計師最大的相同之處是什麼？ 沒錢沒時間沒女朋友

答案是，都很討厭回答 PM 那個令人煩燥的問題：「這個需求很急，什麼時候可以做好？」。

許多朋友可能因此覺得，估計工時一點意義也沒有，反正我盡力完成就是了，能早交付就早交付，你管我估不估計。況且，估算也需要花時間拆解項目，然後以過去經驗評估，要花這個時間的話不如直接開始做，省掉估算的時間不是能夠更快完成嗎？

估算的用途

在 Scrum 中，估算（Estimates）的真正目的是要提供一些可預測性，以及學習感知。前者很好理解，後者我以自己的例子舉例說明：

早年接案做平面設計的時候，不太有時間的概念，每次只要一進入心流狀態，就會完全忘記要喝水、上洗手間，甚至是吃飯，一直到完稿或被中斷。這樣的缺點，就是對於自己需花多少時間才能做完一張品質 90 分的海報完全沒概念，更別說如果今天的需求是只需要 70 分的圖 (例如社群用途求快不求質的情況)，要如何克制、節省時間成本了。

後來 Rson 開始實踐 蕃茄鐘工作法，慢慢地對於時間，有了強感知，也開始能夠估算不同品質要求的圖，每張大概需要幾個「蕃茄」可以完成。如此一來，不但漸漸知道了自己的能耐，同時也能回答出 PM 的那個煩人的萬年問題，「這個設計稿什麼時候可以交付？」

Rson 早年的例子正是 ”估算 → 犯錯 → 下次估算時參考上次的估算並記取教訓 → 幾次後逐漸估計接近準確” 的學習過程。 況且，人的能力是會提升的，使用的工具也是有可能變的更有效率（對不起了錢錢，我需要那個酷東西）。透過每次的估算與事後追蹤，也變的有機會能夠感知到自己成長的喜悅。

相同的道理，在團隊上也是一樣：估算不該是結果導向，而應該是過程導向，無法百分之百精準是一種必然。隨著團隊經驗累積、成熟度變高後，估算能逐漸開始提供它的價值，比如說預先判斷有沒有機會在 Sprint 內順利完成、或者讓團隊警示是不是需要增加人手。

「人們其實不太有能力，去估計任務所需要的確切時間」

另一個好處就是若有一個項目相當難估算，往往代表了它的粒度太大，此時估算就起了一個作用：提醒到團隊需要再把這個項目分解的再小一些。一般來說，超過半天的工作項目，建議應該都要再拆小一點，因為這樣在每日站立會議時，發現夥伴若有一個工項，連續二天都還在進行中（in-progess），就代表一定有某件事卡到陰他，此時 Scrum Master 就能被警示到，需要關心並協助他一起移除障礙。

估算好用三招式

武俠小說裡高人常會說「我讓你三招」，敏捷裡估算工作也有三招，儘管有些在 Scrum 中比較不推薦，但他們在某種程度之上都是有效的。

一、工作小時

這是最傳統的估算方式，雖然 Scrum 本身不建議這種方式，但若一個敏捷團隊還處於一開始非熟練階段，使用傳統的估算小時還是有用的，比如說以 0.5, 1, 2,3,5,8 為可用小時，進行每個任務的估算。在 Sprint 過時中，持續追蹤紀錄剩餘時間，若下降的不夠快，Scrum Master 就得提早警示產品負責人。

以工作小時估算的缺點是容易失控。因為前面提到的，人們對於時間的感知，在平常缺少刻意練習的情況下，幾乎都是高估的。以設計 UI 舉例，想想看上一次你認為改個樣式大概只要 30 分鐘，但改的過程中，發現應該要抽象化出去成為一個元件，接著發現這個新元件需要整進 Guideline 中，整理 Guideline 時為了讓所有抽出來的元件設計上保持一致性，於是又再花一些時間去處理，不知不覺 2 個小時就過去了，與一開始以為的 30 分鐘相比，整整多了 4 倍！

承認吧！我們往往低估了完成事情所需的時間、同時又高估了自己的精力耐力

二、故事點

以工作小時估算會有前面所提到的問題，人類生來更善長相對估算，而非絕對估算，比如面前只有一棟樓 A，我們來問問非理工背景的企畫君－珊迪，這棟樓有多高？她可能會給你一個蝦猜的答案， 30 公分 公尺？

但如果這棟樓的旁邊還有一棟樓 B，我們告訴珊迪 B 棟樓大約 87 公尺，要她估算 A 棟樓幾公尺，那麼相信聰明的珊迪就能很快的做類比，推算出大致正確的高度了。

所以 Scrum 提出了一種指導估算的方式－故事點數（Story Point），正如企劃君珊迪的例子，使用「相對大小」的概念，比較容易估算，具體來說，團隊會事先統一定好 1 點數的故事規模是什麼樣子，比如說刻一個登入登出的畫面，之後任何的工項都以這個為基準做相對估算。

團隊會在規劃時，使用估算遊戲或規劃撲克，為每個故事及工項預估出點數共識。在 Sprint 開始之後，Scrum Master 就只要追蹤這些尚未完成的工作點數就可以了。

三、工作數

有的團隊簡化的更為徹底 隨便，只清點剩餘工作的數量，aka. 傳說中的極簡主義實踐者。

這樣確實會有些項目比其他項目來的大，不太能夠了解項目的大小，不過這個方式總比不估算來的好，此法的缺點顯而易見，無法在一開始發現工作量過大的情況下警示團隊，但優點就是非常的無腦、也至少還有個簡單粗暴可以量化的東西，老闆只要看到可以量化、長的像數字的東西就會龍心大悅？

那麼，哪種方式最好呢？

不同團隊得依照團隊屬性自行決定，唯一的原則，是要能夠在偏離原本計劃時，能夠及早讓團隊發現，及早應對。之後有機會，我們再來寫一篇詳細討論使用故事點數估點的眉眉角角。